v0.0.15

Compare Source

• Bugfix: add missing getter for document.head (#​87, thanks @​rschristian!)

v4.3.3

Compare Source

Patch Release 4.3.3

This is a documentation-only release. Further, the repository was transferred. Please see notes below.

• Migrates repository from https://github.com/visionmedia/debug to https://github.com/debug-js/debug. Please see notes below as to why this change was made.
• Updates repository maintainership information
• Updates the copyright (no license terms change has been made)
• Removes accidental epizeuxis (#​828)
• Adds README section regarding usage in child procs (#​850)

Thank you to @​taylor1791 and @​kristofkalocsai for their contributions.

Repository Migration Information

I've formatted this as a FAQ, please feel free to open an issue for any additional question and I'll add the response here.

Q: What impact will this have on me?

In most cases, you shouldn't notice any change.

The only exception I can think of is if you pull code directly from https://github.com/visionmedia/debug, e.g. via a "debug": "visionmedia/debug"-type version entry in your package.json - in which case, you should still be fine due to the automatic redirection Github sets up, but you should also update any references as soon as possible.

Q: What are the security implications of this change?

If you pull code directly from the old URL, you should update the URL to https://github.com/debug-js/debug as soon as possible. The old organization has many approved owners and thus a new repository could (in theory) be created at the old URL, circumventing Github's automatic redirect that is in place now and serving malicious code. I (@​qix-) also wouldn't have access to that repository, so while I don't think it would happen, it's still something to consider.

Even in such a case, however, the officially released package on npm (debug) would not be affected. That package is still very much under control (even more than it used to be).

Q: What should I do if I encounter an issue related to the migration?

Search the issues first to see if someone has already reported it, and then open a new issue if someone has not.

Q: Why was this done as a 'patch' release? Isn't this breaking?

No, it shouldn't be breaking. The package on npm shouldn't be affected (aside from this patch release) and any references to the old repository should automatically redirect.

Thus, according to all of the "APIs" (loosely put) involved, nothing should have broken.

I understand there are a lot of edge cases so please open issues as needed so I can assist in any way necessary.

Q: Why was the repository transferred?

I'll just list them off in no particular order.

• The old organization was defunct and abandoned.
• I was not an owner of the old organization and thus could not ban the non-trivial amount of spam users or the few truly abusive users from the org. This hindered my ability to properly maintain this package.
• The debug ecosystem intends to grow beyond a single package, and since new packages could not be created in the old org (nor did it make sense for them to live there), a new org made the most sense - especially from a security point of view.
• The old org has way, way too many approved members with push access, for which there was nothing I could do. This presented a pretty sizable security risk given that many packages in recent years have fallen victim to backdoors and the like due to lax security access.

Q: Was this approved?

Yes.^[archive]

Q: Do I need to worry about another migration sometime in the future?

No.

v0.14.0

Compare Source

This release contains backwards-incompatible changes. Since esbuild is before version 1.0.0, these changes have been released as a new minor version to reflect this (as recommended by npm). You should either be pinning the exact version of esbuild in your package.json file or be using a version range syntax that only accepts patch upgrades such as ~0.13.0. See the documentation about semver for more information.

• Add support for TypeScript's preserveValueImports setting (#​1525)

  TypeScript 4.5, which was just released, added a new setting called preserveValueImports. This release of esbuild implements support for this new setting. However, this release also changes esbuild's behavior regarding the importsNotUsedAsValues setting, so this release is being considered a breaking change. Now esbuild's behavior should more accurately match the behavior of the TypeScript compiler. This is described in more detail below.

  The difference in behavior is around unused imports. By default, unused import names are considered to be types and are completely removed if they are unused. If all import names are removed for a given import statement, then the whole import statement is removed too. The two tsconfig.json settings importsNotUsedAsValues and preserveValueImports let you customize this. Here's what the TypeScript compiler's output looks like with these different settings enabled:

  // Original code
  import { unused } from "foo";
  
  // Default output
  /* (the import is completely removed) */
  
  // Output with "importsNotUsedAsValues": "preserve"
  import "foo";
  
  // Output with "preserveValueImports": true
  import { unused } from "foo";

  Previously, since the preserveValueImports setting didn't exist yet, esbuild had treated the importsNotUsedAsValues setting as if it were what is now the preserveValueImports setting instead. This was a deliberate deviation from how the TypeScript compiler behaves, but was necessary to allow esbuild to be used as a TypeScript-to-JavaScript compiler inside of certain composite languages such as Svelte and Vue. These languages append additional code after converting the TypeScript to JavaScript so unused imports may actually turn out to be used later on:

  <script>
  import { someFunc } from "./some-module.js";
  </script>
  <button on:click={someFunc}>Click me!</button>

  Previously the implementers of these languages had to use the importsNotUsedAsValues setting as a hack for esbuild to preserve the import statements. With this release, esbuild now follows the behavior of the TypeScript compiler so implementers will need to use the new preserveValueImports setting to do this instead. This is the breaking change.

• TypeScript code follows JavaScript class field semantics with --target=esnext (#​1480)

  TypeScript 4.3 included a subtle breaking change that wasn't mentioned in the TypeScript 4.3 blog post: class fields will now be compiled with different semantics if "target": "ESNext" is present in tsconfig.json. Specifically in this case useDefineForClassFields will default to true when not specified instead of false. This means class field behavior in TypeScript code will now match JavaScript instead of doing something else:

  class Base {
    set foo(value) { console.log('set', value) }
  }
  class Derived extends Base {
    foo = 123
  }
  new Derived()

  In TypeScript 4.2 and below, the TypeScript compiler would generate code that prints set 123 when tsconfig.json contains "target": "ESNext" but in TypeScript 4.3 and above, the TypeScript compiler will now generate code that doesn't print anything. This is the difference between "assign" semantics and "define" semantics.

  Previously you had to create a tsconfig.json file and specify "target": "ESNext" to get this behavior in esbuild. With this release, you can now also just pass --target=esnext to esbuild to force-enable this behavior. Note that esbuild doesn't do this by default even though the default value of --target= otherwise behaves like esnext. Since TypeScript's compiler doesn't do this behavior by default, it seems like a good idea for esbuild to not do this behavior by default either.

In addition to the breaking changes above, the following changes are also included in this release:

• Allow certain keywords as tuple type labels in TypeScript (#​1797)

  Apparently TypeScript lets you use certain keywords as tuple labels but not others. For example, type x = [function: number] is allowed while type x = [class: number] isn't. This release replicates this behavior in esbuild's TypeScript parser:

  • Allowed keywords: false, function, import, new, null, this, true, typeof, void

  • Forbidden keywords: break, case, catch, class, const, continue, debugger, default, delete, do, else, enum, export, extends, finally, for, if, in, instanceof, return, super, switch, throw, try, var, while, with

• Support sibling namespaces in TypeScript (#​1410)

  TypeScript has a feature where sibling namespaces with the same name can implicitly reference each other's exports without an explicit property access. This goes against how scope lookup works in JavaScript, so it previously didn't work with esbuild. This release adds support for this feature:

  // Original TypeScript code
  namespace x {
    export let y = 123
  }
  namespace x {
    export let z = y
  }
  
  // Old JavaScript output
  var x;
  (function(x2) {
    x2.y = 123;
  })(x || (x = {}));
  (function(x2) {
    x2.z = y;
  })(x || (x = {}));
  
  // New JavaScript output
  var x;
  (function(x2) {
    x2.y = 123;
  })(x || (x = {}));
  (function(x2) {
    x2.z = x2.y;
  })(x || (x = {}));

  Notice how the identifier y is now compiled to the property access x2.y which references the export named y on the namespace, instead of being left as the identifier y which references the global named y. This matches how the TypeScript compiler treats namespace objects. This new behavior also works for enums:

  // Original TypeScript code
  enum x {
    y = 123
  }
  enum x {
    z = y + 1
  }
  
  // Old JavaScript output
  var x;
  (function(x2) {
    x2[x2["y"] = 123] = "y";
  })(x || (x = {}));
  (function(x2) {
    x2[x2["z"] = y + 1] = "z";
  })(x || (x = {}));
  
  // New JavaScript output
  var x;
  (function(x2) {
    x2[x2["y"] = 123] = "y";
  })(x || (x = {}));
  (function(x2) {
    x2[x2["z"] = 124] = "z";
  })(x || (x = {}));

  Note that this behavior does not work across files. Each file is still compiled independently so the namespaces in each file are still resolved independently per-file. Implicit namespace cross-references still do not work across files. Getting this to work is counter to esbuild's parallel architecture and does not fit in with esbuild's design. It also doesn't make sense with esbuild's bundling model where input files are either in ESM or CommonJS format and therefore each have their own scope.

• Change output for top-level TypeScript enums

  The output format for top-level TypeScript enums has been changed to reduce code size and improve tree shaking, which means that esbuild's enum output is now somewhat different than TypeScript's enum output. The behavior of both output formats should still be equivalent though. Here's an example that shows the difference:

  // Original code
  enum x {
    y = 1,
    z = 2
  }
  
  // Old output
  var x;
  (function(x2) {
    x2[x2["y"] = 1] = "y";
    x2[x2["z"] = 2] = "z";
  })(x || (x = {}));
  
  // New output
  var x = /* @​__PURE__ */ ((x2) => {
    x2[x2["y"] = 1] = "y";
    x2[x2["z"] = 2] = "z";
    return x2;
  })(x || {});

  The function expression has been changed to an arrow expression to reduce code size and the enum initializer has been moved into the variable declaration to make it possible to be marked as /* @​__PURE__ */ to improve tree shaking. The /* @​__PURE__ */ annotation is now automatically added when all of the enum values are side-effect free, which means the entire enum definition can be removed as dead code if it's never referenced. Direct enum value references within the same file that have been inlined do not count as references to the enum definition so this should eliminate enums from the output in many cases:

  // Original code
  enum Foo { FOO = 1 }
  enum Bar { BAR = 2 }
  console.log(Foo, Bar.BAR)
  
  // Old output (with --bundle --minify)
  var n;(function(e){e[e.FOO=1]="FOO"})(n||(n={}));var l;(function(e){e[e.BAR=2]="BAR"})(l||(l={}));console.log(n,2);
  
  // New output (with --bundle --minify)
  var n=(e=>(e[e.FOO=1]="FOO",e))(n||{});console.log(n,2);

  Notice how the new output is much shorter because the entire definition for Bar has been completely removed as dead code by esbuild's tree shaking.

  The output may seem strange since it would be simpler to just have a plain object literal as an initializer. However, TypeScript's enum feature behaves similarly to TypeScript's namespace feature which means enums can merge with existing enums and/or existing namespaces (and in some cases also existing objects) if the existing definition has the same name. This new output format keeps its similarity to the original output format so that it still handles all of the various edge cases that TypeScript's enum feature supports. Initializing the enum using a plain object literal would not merge with existing definitions and would break TypeScript's enum semantics.

• Fix legal comment parsing in CSS (#​1796)

  Legal comments in CSS either start with /*! or contain @preserve or @license and are preserved by esbuild in the generated CSS output. This release fixes a bug where non-top-level legal comments inside a CSS file caused esbuild to skip any following legal comments even if those following comments are top-level:

  /* Original code */
  .example {
    --some-var: var(--tw-empty, /*!*/ /*!*/);
  }
  /*! Some legal comment */
  body {
    background-color: red;
  }
  
  /* Old output (with --minify) */
  .example{--some-var: var(--tw-empty, )}body{background-color:red}
  
  /* New output (with --minify) */
  .example{--some-var: var(--tw-empty, )}/*! Some legal comment */body{background-color:red}

• Fix panic when printing invalid CSS (#​1803)

  This release fixes a panic caused by a conditional CSS @import rule with a URL token. Code like this caused esbuild to enter an unexpected state because the case where tokens in the import condition with associated import records wasn't handled. This case is now handled correctly:

  @​import "example.css" url(foo);

• Mark Set and Map with array arguments as pure (#​1791)

  This release introduces special behavior for references to the global Set and Map constructors that marks them as /* @​__PURE__ */ if they are known to not have any side effects. These constructors evaluate the iterator of whatever is passed to them and the iterator could have side effects, so this is only safe if whatever is passed to them is an array, since the array iterator has no side effects.

  Marking a constructor call as /* @​__PURE__ */ means it's safe to remove if the result is unused. This is an existing feature that you can trigger by manually adding a /* @​__PURE__ */ comment before a constructor call. The difference is that this release contains special behavior to automatically mark Set and Map as pure for you as long as it's safe to do so. As with all constructor calls that are marked /* @​__PURE__ */, any internal expressions which could cause side effects are still preserved even though the constructor call itself is removed:

  // Original code
  new Map([
    ['a', b()],
    [c(), new Set(['d', e()])],
  ]);
  
  // Old output (with --minify)
  new Map([["a",b()],[c(),new Set(["d",e()])]]);
  
  // New output (with --minify)
  b(),c(),e();

v13.0.8

Compare Source

v8.4.4

Compare Source

• Fixed absolute path in source map on zero plugins mode.

v8.4.3

Compare Source

• Fixed this.css.replace is not a function error.

v8.4.2

Compare Source

• Fixed previous source map support in zero plugins mode.

v8.4.1

Compare Source

• Fixed Stringifier types (by James Garbutt).

v8.4.0

Compare Source

PostCSS 8.4 brought ranges for warnings and errors, smaller node_modules size, lazy parsing to avoid PostCSS does nothing warning, and TypeScript fixes.

Thanks to Sponsors

This release was possible thanks to our community.

If your company wants to support the sustainability of front-end infrastructure or wants to give some love to PostCSS, you can join our supporters by:

• Tidelift with a Spotify-like subscription model supporting all projects from your lock file.
• Direct donations in PostCSS & Autoprefixer Open Collective.

Rages for Errors and Warnings

@​adalinesimonian, the author of amazing Stylelint extension for VS Code, added ranges to errors and warnings.

result.warn(msg, { index })           // One character warning at index
result.warn(msg, { endIndex })        // Starts at node start, ends at endIndex
result.warn(msg, { index, endIndex }) // Starts at index, ends at endIndex
result.warn(msg, { start })           // Starts at start, ends at node end
result.warn(msg, { end })             // Starts at node start, ends at end
result.warn(msg, { start, end })      // Starts at start, ends at end
result.warn(msg, { word })            // Starts at word location, ends at word index + length

It will improve DX in the IDE extension.

Lazy Parsing

Previously, we found that many tools run PostCSS even if the developer didn’t pass any PostCSS plugins. Parsing is the most expensive step in CSS processing. It led to a waste of resources without any reason.

We tried to resolve the problem by adding a PostCSS does nothing warning. But it didn’t force tool authors to be more careful with user’s resources.

If PostCSS sees that tool call it without passing plugins (or changing parser/stringifier), PostCSS will not parse CSS (until toll will call Result#root). In 8.4, @​bogdan0083 (with the help of @​WilhelmYakunin) tries to solve the problem in another way. It allows us to save resources and remove the PostCSS does nothing warning.

// No plugins, we do not parse CSS
let result = await postcss().process(css, { from  })
result.css  // Is the same string passed to process()
result.map  // Special 1-to-1 source map
result.root // CSS will parsed only here

Install Size Reduction

With ≈60M weekly downloads, PostCSS has responsibility for the world’s resource spending.

Together with @​7rulnik we reduced source-map-js size. It is transitive dependency of PostCSS.

In 8.4, we moved to a fixed version of source-map-js, which reduced the postcss size in your node_modules from ≈1 MB to 0.3 MB. With the huge popularity of PostCSS, it will free a lot of resources on our CIs.

@​kimoofey refactored all tests from the popular Jest framework to small and fast uvu.

It will not affect end-users. However, it reduced our node_modules size by 33 MB and made tests twice faster (yarn install & yarn unit: 24 → 13 seconds).

TypeScript Fixes

• Added Processor types.
• Added Stringifier types (by @​43081j).
• Fixed types Root and Document in result values (by @​43081j).
• Fixed Node#walkRules() types (by @​hudochenkov).

Other Changes

• Fixed docs (by @​paulshryock).

v6.2.1

Compare Source

v1.43.5

Compare Source

• Fix a bug where calculations with different operators were incorrectly
  considered equal.

• Properly parse attribute selectors with empty namespaces.

JS API

• Print more detailed JS stack traces. This is mostly useful for the Sass team's
  own debugging purposes.

v5.64.4

Compare Source

Bugfixes

• fix tagged template literal evaluation
• fix ModuleFederation with ESM
• fix outputModule with intial splitChunks

Performance

• upgrade watchpack for faster watcher updating
• track file and directory timestamps separately in watchpack and webpack

Developer Experience

• show origin of singleton shared module in mismatch warning

v4.6.0

Compare Source

Features

• allow to pass all chokidar options (#​4025) (5026601)

Bug Fixes

• reconnection logic (#​4044) (9b32c96)
• reload on warnings (#​4056) (1ba9720)